Based on your comments on the issue then this would break compatibility with k8s <1.9, is the 1.8 version something that was previously supported by this plugin? If so, we probably need to add an option to opt into this change. Either way we should document the first version this plugin supports. Were these new APIs also added in 1.9?

1.8 has been EOL for a year. Of course, that doesn't mean people aren't still on it.

These changes will break for <= 1.8

We could check the API version and act accordingly, but I'd be worried about how long that code would be there and how many code paths we'll have after another year of Kubernetes releases (minor release every 16 weeks)

What do you think is best?

If it used to work, but now it doesn't, we ought to keep it around. Unless we have a strong belief that no one is using it with 1.8 or older. When was 1.9 released?

Either way I'd really like to set the bar with a minimum supported version in the documentation.

1.9 was released December 2017

As we discussed offline, let's document in the README (last paragraph of the first section) the minimum version that we are going to support going forward with this plugin. Set it to the oldest version supported by AWS+GCP+Azure, we can use the new API from this PR without keeping around the legacy support.

TL;DR

No major cloud provider allows for a version that wouldn't include support for the v1 APIs

AWS

Q: Which Kubernetes versions does Amazon EKS support?

A: Amazon EKS supports Kubernetes version 1.11, 1.12, 1.13, and 1.14 and will continue to add support for additional Kubernetes versions in the future.

GKE

gcloud container get-server-config --zone us-west2

While worker versions can use from >= 1.6.13, master nodes (which the API Server runs on) only supports >= 1.12.10

validMasterVersions:
- 1.14.7-gke.10
- 1.14.6-gke.13
- 1.14.6-gke.2
- 1.14.6-gke.1
- 1.13.11-gke.5
- 1.13.10-gke.7
- 1.13.10-gke.0
- 1.13.9-gke.11
- 1.13.9-gke.3
- 1.13.7-gke.24
- 1.12.10-gke.15

AKS

Azure supports 4 minor versions, which means >= 1.13.0

@danielnelson Updated. Please let me know if this is what you had in mind, or if you'd like further changes. Thanks for your continued assistance 👍

So let's say 1.11 is the first version we will support. Can you verify your changes are working with 1.11 then and add a paragraph to the readme:

This plugin supports Kubernetes 1.11 and later.

Confirmed working. Steps to reproduce:

Get a Kubernetes 1.11 cluster

minikube start --vm-driver=kvm2 --kubernetes-version=v1.11.0

Save Dockerfile to Telegraf local clone:

#Dockerfile
FROM ubuntu:18.10
COPY ./telegraf /bin/telegraf

ENTRYPOINT ["/bin/telegraf"]

Build custom Telegraf from branch:

eval $(minikube docker-env)
# This builds it within your minikube cluster
docker image build -t telegraf:kube111 .

Deploy Telegrafs

git clone https://github.com/rawkode/influxdb-examples
cd influxdb-examples/kubernetes

# YOU NEED TO UPDATE ALL THE `telegraf.yaml` FILES TO USE `image: telegraf:kube111` AND ADD `imagePullPolicy: IfNotPresent` to the line after each

make

Check it's working:

kubectl port-forward -n monitoring svc/influxdb 9999:9999

Browsing to http://localhost:9999 and you should be able to explore metrics for apps/v1 resources, such as statefulsets, deployments, and daemonsets

This plugin supports Kubernetes 1.11 and later.

Added to both README.md's